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ABSTRACT 

The  transition  of  new  C2ISR  technologies  and  capabilities  to  the  warfighter  in  a  useful  and 
timely  manner  is  a  longstanding  challenge,  which  is  often  met  through  unique  solutions  to 
specific  warfighter  problems,  and  often  compromising  interoperability  in  combat  and  other  field 
operations.  Interoperability  is  now  a  major  concern  and  the  focus  of  C2ISR  development.  The 
most  effective  way  to  address  this  concern  is  through  the  integrated  development  of  C2ISR 
components.  However,  integration  is  not  readily  accommodated  in  the  present  acquisition  and 
PPBS  processes,  one  reason  why  there  has  been  lots  of  discussion  with  modest  results.  In  this 
paper  we  recommend  a  new  approach  to  integration,  namely  that  integration  be  viewed  as  an 
explicit  result,  not  just  as  an  attribute  of  C2ISR  systems.  We  then  look  at  the  processes  and  the 
problems  from  this  perspective  and  make  some  recommendations  for  providing  integrated  and 
interoperable  new  technology  to  the  warfighter  in  a  timely  manner. 
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1.  Introduction 


Joint  Vision  2010  [JV2010,  1996]  defines  Information  Superiority  as:  The  capability  to  collect, 
process,  and  disseminate  an  uninterrupted  flow  of  information  while  exploiting  or  denying  an 
adversary’s  ability  to  do  the  same.  This  represents  an  ambitious  vision.  It  is  our  contention  that 
many  of  the  difficulties  of  DoD  programs,  which  have  addressed  this  vision,  originate  in  the 
inadequate  translation  of  integration  requirements  for  this  global  vision  into  practical,  specific 
results. 

“Making  Information  Superiority  Happen”  is  primarily  a  problem  in  consistency,  coherence,  and 
compatibility  among  the  command,  control,  intelligence,  surveillance,  and  reconnaissance 
(C2ISR)  capabilities.  Our  existing  C2ISR  systems  provide  much  of  the  information  that  is 
necessary,  but  because  the  systems  are  not  integrated,  and  are  not  interoperable,  the  information 
is  not  readily  available  to  the  warfighter.  There  are  a  variety  of  reasons  for  this.  For  instance: 

•  The  warfighter  does  not  have  access  to  one  of  the  systems  needed  and  only  that  system  can 
access  the  data. 

•  The  warfighter  has  access  to  the  system  but  does  not  know  how  to  use  it  because  it  does  not 
behave  like  any  of  the  systems  with  which  he/she  is  familiar. 

•  The  warfighter  can  operate  the  system  but  cannot  relate  the  output  to  the  products  of  other 
systems. 

Today  new  technologies  are  still  often  fielded  as  stand-alone  capabilities,  which  the  warfighter 
may  ignore  or  reject  because  it  adds  complexity  to  his/her  operations.  For  new  technologies  to 
be  readily  acceptable,  integration  and  interoperability  (I&I)  have  to  be  “designed  in.”  Consider 
Microsoft  Office,  the  dominant  office  automation  suite.  It  provides  office  information 
superiority  because  all  components  are  well  integrated  and  behave  similarly  to  all  other 
components.  Once  the  user  becomes  familiar  with  any  one  component,  getting  started  on  any 
other  component  is  relatively  easy.  In  addition,  the  product  of  any  component  can  be  easily 
combined  with  the  product  of  other  components  to  provide  an  integrated  result.  This  is  the 
antithesis  of  our  current  C2ISR  systems  where  each  one  is  an  island  unto  itself. 

Our  task,  as  the  Integrated  C2ISR  System  Program  Office  (IC2ISR  SPO),  is  to  make  C2ISR  I&I 
a  reality  by  ensuring  the  I&I  of  fielded  versions  of  new  technologies  and  enhanced  C2ISR 
systems  into  a  compatible,  coherent,  and  consistent  system-of-sy stems:  the  Integrated  C2ISR 
(IC2ISR).  This  paper  examines  the  inherent  difficulties  in  accomplishing  this  within  the  existing 
acquisition  process. 

2.  Taxonomy 

Terms  such  as  integration,  interoperability,  architecture,  and  others  used  in  discussing  IC2ISR 
have  as  many  definitions  as  there  are  participants.  Although  many  of  these  definitions  are 
effective  for  their  intended  audiences,  they  are  often  too  specific  and  too  detailed  for  our 
purposes.  In  particular,  we  believe  that  the  focus  on  precision  has  blinded  architects  and  system 
engineers  to  larger  and  more  global  issues,  which  may  be  the  sources  of  many  of  the 
architectural  and  system  integration  problems  of  past  DoD  programs. 


CJCS  Instruction  6212. OlA,  Compatibility,  Interoperability,  and  Integration  of  Command, 
Control,  Communications,  Computers,  and  Intelligence  Systems  [CJCS6212,  1995]  defines 
integration  and  interoperability  as  follows: 

•  Integration  —  The  arrangement  of  systems  in  an  architecture  so  that  they  function  together  in 
an  efficient  and  logical  way. 

•  Interoperability  —  The  ability  of  the  systems,  units,  or  forces  to  provide  services  to  and 
accept  services  from  other  systems,  units,  or  forces,  and  to  use  the  services  so  exchanged  to 
enable  them  to  operate  effectively  together.  The  conditions  achieved  among 
communications-electronics  systems  or  items  of  communications-electronics  equipment 
when  information  or  services  can  be  exchanged  directly  and  satisfactorily  between  them 
and/or  their  users. 

These  definitions  address  attributes,  rather  than  results,  a  distinction  that  underlies  the 
difficulties  in  achieving  IC2ISR. 

For  purposes  of  this  paper  we  will  use  the  following  definitions  which  explicitly  include  the 
notion  of  “result”: 

•  Integration  —  The  implemented  set  of  requirements,  designs,  processes,  documentation, 
training  and  tests  that  combine  two  or  more  entities  into  a  larger  whole  to  produce  a  specific 
result. 

•  Interoperability  —  The  capability  provided  through  detailed  interfaces  between  two  or  more 
entities,  which  allow  these  entities  to  work  together  on  common  data  or  in  a  common 
environment  without  conflict,  to  contribute  to  a  specific  result. 

•  Architecture  —  The  overall  design  of  an  entity  that  combines  components  in  a  coherent  and 
organized  fashion  to  deliver  a  specific  result. 

3.  Integration  Examined 

A  paper  at  last  year's  Command  and  Control  Research  and  Technology  Symposium  entitled 
Architecture:  The  Road  to  Interoperability,  [Curts  and  Campbell,  1999]  examined  some  of  the 
history  of  DoD  interoperability  and  concluded  that  a  DoD-wide  interoperable  C4I  architecture 
was  necessary.  In  the  spirit  of  their  paper  we  would  like  to  subtitle  our  paper  as  “Integration: 
The  Pavement  for  Interoperability.”  A  good  architecture  under  DoD-wide  authority  will  only 
have  an  impact  if  the  underlying  pavement  is  sound.  Integration  is  the  practical  engineering 
implementation  of  architectural  plans. 

In  designing  and  erecting  buildings,  there  is  a  significant  gap  between  the  architectural  drawings 
and  an  operational  functioning  building.  So  too  in  creating  C2ISR  interoperable  systems,  there  is 
a  gap  between  the  architecture  and  the  working  system-of-systems  that  implements  the 
architecture.  By  our  definition,  integration  bridges  this  gap  as  it  implements  the  set  of  processes 
to  bring  individual  component  systems  together  in  a  coherent  fashion  to  achieve  a  specific  result. 


3.1  Integration  as  a  Result 


The  emphasis  on  result  is  quite  intentional.  It  is  our  contention  that  most  of  the  difficulties  in 
achieving  C2  Integration  arise  because  integration  is  not  recognized  as  a  result  in  its  own  right. 
Too  often,  in  our  opinion,  architectures  have  been  interpreted  as  needing  to  provide  all  things  to 
all  warfighters,  and  as  a  consequence  either  fail  completely  or  are  delayed  so  long  that 
technology  advances  render  them  obsolete  before  they  are  delivered.  Successful  integration 
includes  the  willingness  of  an  IC2ISR  program  to  compromise  “architectural  elegance”  in  favor 
of  delivering  results,  particularly  when  addressing  the  boundaries  of  systems  and  connections  to 
existing  legacy  systems. 

An  effective  I&I  process  to  deliver  IC2ISR  requires  recognition  that  integration  is  not  just  an 
aesthetically  pleasing  property.  It  provides  concrete  value  to  systems,  especially  to  systems-of- 
systems,  making  IC2ISR  more  than  just  the  sum  of  its  parts.  The  value  of  an  IC2ISR  lies  in  the 
result,  which  is  achieved  by  subordinating  individual  component  capabilities  to  the  greater 
combined  IC2ISR  capabilities. 

3.2  Cost  of  Lack  of  Integration 

Integration  in  normal  DoD  program  acquisition  terms  is  considered  an  attribute  of  a  system, 
similar  to  and  comparable  with  other  attributes  such  as  reliability,  supportability,  performance, 
etc.  This  leads  to  thinking  of  integration  as  part  of  the  trade  space  in  developing  systems,  so  that 
integration  may  be  sacrificed  to  achieve  some  other  system  attribute.  For  example,  valid 
technical  tradeoffs  may  lead  component  X  to  choose  to  forgo  integration  with  component  Y  in 
order  to  increase  reliability,  reduce  network  load  or  satisfy  some  other  mission  requirement.  But 
this  tradeoff,  made  multiple  times  across  multiple  components,  leads  to  a  C2ISR  environment 
filled  with  special  cases,  exemptions,  unique  interfaces  and  partial  interoperability  that  causes 
problems  for  the  warfighter  trying  to  work  with  the  C2ISR  system  as  a  whole: 

•  Standard  configurations  are  not  developed  because  individual  sites  will  not  accept 
components  that  are  not  directly  relevant  to  their  mission  in  order  to  avoid  component- 
specific  issues. 

•  Site-specific  development  occurs  to  satisfy  specific  needs  for  component  integration  not 
provided  by  the  system.  Creative  warfighters  find  solutions  to  their  problems,  but  those 
solutions  may  not  be  generally  applicable  or  supportable. 

•  The  growth  of  site-specific  components  exacerbates  the  training  problem  since  no  two 
installations  use  the  same  tools  and  processes  to  accomplish  a  given  mission.  Training  is 
complex  because  each  component  has  its  unique  list  of  interfaces  and  exemptions  and  few 
general  conclusions  can  be  drawn  about  how  things  work. 

3.3  Value  of  Integration 

Integration  as  a  result  provides  the  following  capabilities,  which  otherwise  would  be  missing  or 
weak  in  a  comparable  system  where  integration  is  considered  an  attribute. 

•  Multiple  pathways  to  achievement.  Focusing  on  integration  provides  a  broader  scope  for 
technical  analysis.  Compromises  among  components,  “glueware”  interfaces  and  other 


techniques  become  realistic  alternatives  for  achieving  IC2ISR.  If  integration  is  merely 
viewed  as  an  attribute,  the  range  of  evaluation  will  be  limited  to  binary  (e.g.,  “yes/no”)  or 
linear  (e.g.,  “k%  of  the  message  formats  processed”)  characteristics. 

•  Greater  flexibility  in  tradeoffs  among  product  components.  The  trade  space  in  a  system 
containing  conflicts  between  components  A  and  B  is  wider  than  it  would  be  for  a  component 
alone  as  shown  in  the  table  below. 


Component  A 
Integration  as  Attribute 
Individual  Tradeoffs 

Component  B 
Integration  as  Attribute 
Individual  Tradeoffs 

Components  A  &  B 
Integration  as  Result 
Combined  Tradeoffs 

Get  B  to  Change 

Get  A  to  Change 

Change  A 

Drop  integration  with  B 

Drop  integration  with  A 

Change  B 

Change  A  and  B 

Introduce  glueware  G 

Table  1.  Comparative  Trade-off  Flexibility  with  Integration  Viewed  as  Attribute  versus  Result. 


•  Standardization  and  commonality  in  multiple  installations.  The  IC2ISR  is  less  likely  to  be 
partially  deployed  or  broken  apart  for  local  conditions. 

•  Shared  services  and  shared  capabilities.  If  components  X  and  Y  are  integrated,  a  new 
capability  in  X  will  be  relatively  easy  to  share  with  Y,  so  Y  will  be  less  likely  to  build  its 
own  version  of  that  capability. 

•  Easier  customization.  The  IC2ISR  provides  an  architectural  base  for  “common  look  and 
feel”  enhancements  that  fit  directly  into  the  integrated  “environment.”  Consider  adding  a 
capability  to  Microsoft  Office:  by  fitting  into  the  integrated  environment  the  compatibility  of 
the  added  capability  is  assured. 

•  Simplified  training  and  operator  refresh  cycles.  Once  people  are  familiar  with  the  basic 
integrated  environment  they  more  easily  learn  new  capabilities  that  come  as  upgrades  or 
additions  to  the  base  system. 

•  Reduced  long-term  costs.  Initially,  integration  appears  costly,  because  in  a  fiscally 
constrained  environment,  integration  costs  may  compromise  the  achievement  of  some 
desired  system  capabilities.  Also,  costs  are  incurred  “up  front”  where  there  is  greater 
visibility  without  corresponding  visibility  into  the  benefits  of  integration.  However,  as 
IC2ISR  evolves,  it  becomes  less  costly,  because  new  capabilities  and  new  technologies  are 
developed  as  integral  to  IC2ISR  without  incurring  separate  integration  costs.  Additional 
savings  result  from  the  reduced  costs  for  training  and  sustainment  because  of  the  inherent 
commonality. 

3.4  Principles  for  Integration  projects 

In  DoD  Legacy  System  Migration  Guidelines  [Bergey,  et  ah,  1999],  ten  basic  guidelines  are 
presented  to  help  “understand  the  perspective  of  development/system  migration  organization,  in 
order  to  make  smart  technical  choices  and  to  follow  a  disciplined  reengineering  process.”  If  you 
replace  the  word  “reengineering”  with  “integration”  it  is  almost  perfectly  applicable  to  IC2ISR. 


To  build  IC2ISR  will  require  literally  reengineering  the  way  we  do  business  (i.e.,  integrate, 
develop,  and  deploy  C2  and  ISR  systems).  This  paper  addresses  the  challenge  of  working  with 
legacy  systems,  which  is  a  long-standing  deterrent  to  IC2ISR.  It  contains  some  very  sound,  and 
thought  provoking,  information  that  applies  directly  to  our  tasks  and  identifies  ways  we  may 
succeed  or  fail.  Summaries  of  the  ten  guidelines  are: 

1.  Develop  a  comprehensive  strategy  with  achievable  and  measurable  milestones  for  each 
integration  project. 

2.  When  outside  systems  engineering  services  are  needed,  carefully  define  and  monitor  their 
roles. 

3.  If  new  technology  is  used  for  a  project,  provide  adequate  training  in  both  the  technical 
content  and  the  motivation  for  change. 

4.  Establish  and  maintain  configuration  management  control  of  the  legacy  system. 

5.  There  should  be  a  carefully  defined  and  documented  process  for  the  elicitation  and  validation 
of  requirements. 

6.  Make  software  architecture  a  primary  integration  consideration. 

7.  There  should  be  a  separate  and  distinct  integration  process. 

8.  Create  a  team-oriented  integration  plan  ...  and  follow  it. 

9.  Management  needs  to  be  committed  for  the  long  haul. 

10.  Management  edicts  should  not  override  technical  realities. 

3.5  Integration  Strategy 

The  complexity  of  integrating  C2ISR  systems  greatly  exceeds  the  ability  of  our  development, 
testing,  and  certification  resources  to  cope  if  we  try  to  address  the  entire  aggregate  of  C2ISR 
systems  which  have  evolved  independently  as  a  loose  collection  of  systems.  Therefore,  for 
integration  to  succeed,  it  must  occur  through  an  iterative  process.  Each  iteration  of  the  IC2ISR 
needs  to  be  constrained  to  a  manageable  set  of  changes  and  a  specific  set  of  results,  which  we 
call  a  "Block."  This  type  of  iterative  strategy  is  an  example  of  Evolutionary  Acquisition,  as 
directed  by  Air  Eorce  Program  Directive  63-1,  Acquisition  System,  [AEPD63-1,  1993]. 

Building  an  IC2ISR  Block  includes  balancing  technology  and  system  advancement  against  four 
categories  of  constraints: 

•  Technology  Refresh  Cycle  —  the  amount  of  time  required  to  replace  the  technology  base  to 
execute  the  Block.  This  is  a  function  of  both  the  rate  of  commercial-off-the-shelf  (COTS) 
technology  change  and  the  investment  capability  of  the  organization. 

•  Infrastructure  Refresh  Cycle  —  the  amount  of  time  required  to  replace  or  upgrade  the 
technology  infrastructure  (base  networks,  telephone  capacity,  etc.)  that  supports  the  Block. 

•  Warfighter  Training  Refresh  Cycle  —  the  amount  of  time  required  to  educate  all  of  the 
people  who  will  interact  with  the  Block.  (Users,  operators,  system  administrators, 
infrastructure  administrators,  etc.) 


•  Funding  Refresh  Cycle  —  the  amount  of  time  required  to  react  and  reprogram  funds  and 
resources  to  develop  new  Blocks,  revise  old  Blocks,  react  to  technology  changes,  etc. 

Each  IC2ISR  Block  specifies  a  manageable  number  of  coherent,  connected  system  changes  that 
collectively  provide  a  new  or  enhanced  capability  to  the  warfighter.  For  example,  a  given  block 
may  be  focused  on  enhancing  warfighter  display  technology.  The  major  theme  of  the  block 
might  then  revolve  around  delivering  a  Single  Integrated  Aerospace  Picture  (SIAP).  Themes  of 
the  block  would  lie  in: 

•  Technical  development  to  enhance  visual  display,  imaging,  information  fusion  capabilities. 

•  Technology  refresh  for  larger,  better  display  systems. 

•  Infrastructure  refresh  for  transmission,  dissemination  and  distribution  of  visual  information. 

If  on  the  other  hand,  a  block  is  focused  on  improving  system  administration  and  reducing 
footprint,  the  themes  of  the  block  might  lie  in: 

•  Technical  development  of  remote  system  management  tools. 

•  Technology  refresh  of  laptops,  notebooks  and  handhelds. 

•  Infrastructure  refresh  for  remote  database  support  and  faster  long-haul  circuits. 

There  is  a  set  of  mutually  supporting  reasons  for  constraining  a  block  to  one  or  two  capability 
areas: 

•  The  technology  and  infrastructure  refresh  cycles  are  limited  in  capacity  and  need  to  operate 
in  harmony  to  keep  the  system  in  balance. 

•  Integration  is  a  complex  process  and  convergence  cannot  be  assured  if  all  parts  of  the  system 
are  free  to  change. 

•  Tradeoff  analyses  and  risk  mitigation  need  a  prioritization  process,  which  flows  naturally 
from  block  themes. 

3.6  Building  IC2ISR  Blocks 

Building  an  IC2ISR,  and  adding  new  technologies  and  new  capabilities,  generates  new 
requirements  and  requires  new  processes.  There  are  new  warfighter  requirements,  development 
activities,  test  and  certification  activities,  and  fielding  and  sustainment  requirements  inherent  in 
developing  IC2ISR.  Part  of  every  phase  of  the  acquisition  process  of  every  component  needs  to 
be  focused  on  identifying  and  satisfying  I&I  requirements.  The  table  below  describes  some  of 
the  acquisition  process  tasks  needed  to  deliver  an  IC2ISR  Block,  beyond  what  is  needed  to 
deliver  an  isolated  system. 


Task 

Task  Description 

Current  System 
Architecture  Analysis 

Perform  and  document  current  system  architecture  within  the  scope 
of  the  block. 

Current  Infrastructure 
Architecture  Analysis 

Document  current  infrastructure  architecture  within  the  scope  of  the 
block. 

Current  Training 
Architecture  Analysis 

Document  current  training  architectures  and  resource  materials. 

New  System  Architecture 
Requirements  &  Analysis 

Develop  the  block  system  architecture  to  support  the  new  block 
requirements. 

Risk  Analysis 

Develop  the  prioritized  risk  analysis  &  mitigation  strategies. 

Components'  Entrance 
Criteria 

Develop  the  components'  entrance  criteria  for  the  block. 

Infrastructure  Change 
Proposal 

Develop  the  required  infrastructure  changes  needed  to  support  the 
block.  Perform  comparative  analysis  on  existing  communications 
and  COTS  versus  requirements. 

Block  Packaging  Design 

Develop  packaging  plan  and  design. 

Integration  Infrastructure 

Set  up  simulated  site  infrastructure  baseline. 

Component  Entrance 
Criteria  Validation 

Validate  that  the  component  has  achieved  all  required  entrance 
criteria. 

Component-  specific 
Installation 

Eor  each  component,  install  on  integration  base 
(Comm/Sys/OS/Apps). 

Integration 

Make  components  work  together  as  a  block. 

Glueware  Development 

Develop,  or  sponsor  development,  of  any  required  glueware. 

Develop  Configuration 
Parameters 

Eor  each  component,  develop  configuration  and/or  setup  parameters 
that  enable  component  to  work  in  block. 

Develop  Installation 
Procedures 

Eor  each  component,  develop  block  installation  and/or  setup 
parameters  that  enable  component  to  be  installed  in  block. 

Integration  Validation 

End-to-end  block  validation. 

Compile  Block  Package 

Develop  block  package  comprising  all  components,  configuration 
parameters,  installation  instructions,  etc. 

Integrated  Site  Training 

Develop  an  integrated  training  package  for  sites  with  a  common 
approach,  common  materials  and  Block-oriented  focus. 

Table  2.  Integration-Specific  Acquisition  Process  Tasks 


More  resources  are  needed  to  produce  an  interoperable,  integrated  product  than  to  build  a 
stovepipe  system.  However,  it  is  more  expensive  to  try  to  retrofit  systems  for  interoperability 
than  to  build  them  as  integrated,  interoperable  components  of  an  IC2ISR.  This  means  that  future 


systems,  and  future  versions  of  existing  systems,  must  have  IC2ISR  requirements  as  a  high 
priority  in  the  individual  system's  requirements  analysis  process. 

4.  Acquisition  Process  versus  Integration  Programs 

The  current  Defense  Systems  Acquisition  Management  Process,  as  documented  in  the  DoD  5000 
series  documents,  is  not  designed  to  support  IC2ISR  effectively.  The  major  functional 
disciplines  of  the  acquisition  process  are  not  structured  for  Integration  Programs,  as  indicated  by 
the  problems  identified  with  each  in  the  following. 

Acquisition  Policy  —  The  typical  time  frame  for  each  phase  of  the  typical  process  is  measured  in 
years.  For  IC2ISR  programs,  an  entire  Block  cycle,  as  driven  by  COTS  technology  change, 
takes  approximately  three  years  from  initiation  to  disposal.  In  particular,  the  ratio  of  time  spent 
in  development  to  time  spent  in  operation  ranges  from  Va  to  V2  for  traditional  programs;  for 
C2ISR  integration  programs,  the  ratio  is  close  to  1.  Evolutionary  acquisition  strategy,  which  is 
designed  to  reduce  the  time  to  field  a  capability,  addresses  one  of  the  difficulties  with  the  present 
acquisition  process. 

Program  Management  and  Leadership  —  Given  that  integration  is  viewed  as  an  attribute  of 
individual  programs,  there  are  no  “Integration  Programs”  per  se,  creating  serious  challenges. 

•  Planning  -  Integration  programs  include  components  that  are  separately  funded, 
scheduled,  and  controlled,  which  greatly  complicates  planning. 

•  Organizing  and  Staffing  -  Integration  programs  place  a  premium  on  technical 
sophistication  and  continuity  of  architecture  and  goals,  but  they  have  relatively  short  time 
frames  in  which  to  build  and  sustain  organizational  memory. 

•  Controlling  -  As  with  planning,  the  relationship  of  the  integration  program  to  its 
components  creates  unique  complexity  for  controlling,  and  for  managing  tradeoffs,  risks 
and  decision-making  across,  independent  components. 

•  Leading  -  Programs  are  managed  and  funded  through  PEOs  and  DACs.  There  is  no  PEG 
for  C2ISR  integration,  nor  is  there  a  single  PEG  for  C2ISR  programs.  C2ISR  programs 
are  scattered  across  portfolios  of  several  PEGs  and  DACs.  With  no  single  entity 
responsible  for  IC2ISR,  there  can  be  no  program. 

Earned  Value  Management  —  Integration  programs  are  inherently  complex,  and  integration 
activities  at  present  are  analogous  to  R&D  efforts  in  that  the  effort  required  to  produce  the 
desired  results  is  not  clearly  defined.  The  result  is  binary,  either  success  or  failure,  and  does  not 
lend  itself  readily  to  measuring  progress. 

Contract  Management  —  The  contractor  must  provide  an  integrated  C2ISR  “whole”  although  he 
does  not  control  components’  costs  and  schedules.  Contracting  is  complex,  and  standard 
processes  for  managing  contracts  do  not  address  this  complexity. 

Funds  Management  —  The  basic  funding  process,  the  Planning,  Programming,  and  Budgeting 
System  (PPBS),  has  a  cycle  that  exceeds  the  typical  C2ISR  integration  program  life  cycle. 


Funding  for  integration  must  be  included  in  the  PPBS  process  before  there  is  much 
understanding  of  exactly  what  will  be  integrated  or  how  complex  the  integration  task  will  be. 
Funding  can  be  justified  only  in  generic  integration  terms,  not  as  specific  products.  In  this 
process,  a  “funding  wedge”  is  required,  which  is  at  best  a  guess  at  what  the  required  funding  will 
be.  In  addition,  there  is  a  minimum  level  of  funding  required  each  year  simply  to  maintain  the 
integrity  of  the  existing  IC2ISR  and  deliver  Block  maintenance  and  support. 

Systems  Engineering  —  Current  systems  engineering  addresses  integration  as  an  attribute.  The 
requirements  process  reinforces  this  because  integration  as  a  result  is  not  visible  to  the 
warfighters  at  this  time.  Where  current  C2ISR  systems  are  adequate  to  their  specific  mission,  the 
advantages  of  IC2ISR  are  not  readily  apparent.  Where  they  are  not,  requirements  focus  on  new 
capabilities,  but  not  on  integration.  A  significant  change  of  focus  is  needed  to  view  integration 
as  a  result.  Once  given  an  integrated  environment,  however,  the  benefits  of  integration  will 
become  obvious  to  the  warfighter,  and  he/she  will  drive  the  requirements.  But  initially, 
requirements  for  integration  must  come  from  other  sources  to  provide  the  necessary  impetus. 

Software  Acquisition  Management  —  Integration  is  predominantly  a  software  phenomenon  for 
C2ISR.  Current  processes  are  oriented  toward  development  of  new  capabilities,  but  IC2ISR  is 
not  a  “development”  program  in  the  traditional  sense,  because  no  software  is  planned  as  part  of 
the  program.  Review,  management  and  control  procedures  must  be  enhanced  to  focus  on  the 
“back-end”  of  the  process  where  integration  efforts  are  predominant. 

Test  and  Evaluation  —  T&E  processes  must  be  enhanced  to  measure  and  assess  integration  as  a 
specific  result  of  a  C2ISR  system.  Current  methodologies  are  oriented  toward  either  low-level 
functional  testing  or  to  specific  mission-thread  testing  and  not  towards  the  overall  analysis  of  the 
integrated  C2ISR  “whole.” 

Manufacturing  and  Production  —  Manufacturing  and  production  must  be  redefined  for  delivery 
of  integrated  C2ISR  systems,  with  emphasis  on  new  and  innovative  packaging,  baselining  and 
configuration  management  capabilities  to  provide  multiple  components  in  a  single  package.  The 
adoption  of  DII-COE  with  its  processes  and  standards  for  segmentation,  compliance  and 
configuration  management  shows  the  way  toward  addressing  these  difficulties. 

Acquisition  Logistics  —  Support  elements  must  be  focused  on  the  integrated  C2ISR  “whole”. 
Current  component-specific  help-desks  and  maintenance  procedures  also  must  be  integrated  to 
become  part  of  the  integrated  C2ISR  support  and  sustainment  processes. 

5.  Discussion 

IC2ISR  is  an  investment  that  provides  added  value  for  the  warfighter  through  ease  of  training, 
operations,  and  maintenance,  and  is  cost  effective  as  well,  over  the  long  term.  The 
standardization  and  commonality  in  installations,  which  results  from  integration,  reduces 
training,  installation,  and  support  costs.  These  benefits  are  not  realized  immediately.  Rather 
what  is  immediately  apparent  is  that  integration  requires  an  investment  up  front,  which  either 
adds  to  the  cost  of  developing  new  capabilities  or  requires  that  capabilities  be  compromised  to 
support  integration.  Given  the  choice,  integration  is  often  sacrificed.  Although  it  is  commonly 


accepted  that  integration  and  interoperability  are  desirable,  to  date,  there  is  no  incentive  for  the 
initial  investment. 

Acquisition  and  funding  processes,  not  defined  with  integration  programs  in  mind,  create 
additional  problems.  The  evolutionary  acquisition  strategy  approximates  what  is  needed  for  the 
integration  program,  but  other  than  addressing  the  time  to  fielding  of  a  capability,  it  does  not 
address  the  many  other  problems  with  the  traditional  acquisition  process.  Management  of  the 
IC2ISR  program  and  processes  also  is  an  issue.  The  typical  program  management  structure 
requires  some  modification  to  manage  the  IC2ISR  effectively. 

5.1  Management 

The  process  of  building  an  effective  integrated  C2ISR  system  requires  some  enhancements  to  the 
existing  management  process. 

•  PEO  for  IC2ISR.  This  PEO  would  be  responsible  solely  for  the  execution  of  IC2ISR, 
cooperating  with  the  PEOs  and  DACs  of  the  C2ISR  programs  to  develop  integration 
strategies,  schedules,  and  budgets.  The  IC2ISR  program  also  should  be  assigned  to  a  single 
Mission  Area  Director  (MAD)  for  representation  through  the  Air  Eorce  Corporate  Process. 
This  would  give  IC2ISR  the  focus  and  advocacy  it  now  lacks  in  the  PPBS  process. 

•  Management  by  C2ISR  Integration  Office  comprised  of  IPTs.  Because  the  IC2ISR  requires 
inputs  from  multiple  programs  that  are  controlled  and  funded  independently,  it  cannot  be 
managed  as  a  typical  development  program.  Rather  than  a  systems  program  office  (SPO),  it 
should  be  a  system  integration  office  that  leads  the  requisite  IPTs  to  accomplish  the 
integration.  Several  IPTs  will  be  required,  with  membership  to  include  representatives  from 
the  Joint  Staff,  OSD,  other  Services,  other  Product  Centers,  members  from  the  SPOs 
providing  Block  components,  and  other  IPT-specific  members. 

-  C21SR  Interoperability  Requirements  IPT.  This  IPT  will  introduce  I&I  requirements  into 
the  system  acquisition  process  at  an  early  stage  and  provide  justification  and 
rationalization  during  the  typical  risk  management  and  tradeoff  analysis  activities  that 
occur  in  the  development  phase.  This  IPT  is  responsible  for  coordinating  I&I 
requirements  across  C2ISR  systems  and  for  identifying  alternatives  as  needed.  Since  I&I 
requirements  are  inherently  shared  between  systems,  I&I  implementation  decisions 
cannot  be  made  by  an  individual  system.  Eor  example,  if  system  A  cannot  fulfill  a  given 
I&I  requirement,  the  IPT  will  be  responsible  for  developing  a  technical,  system,  and/or 
operational  alternative  so  that  overall  block  I&I  capabilities  are  not  compromised. 

-  C21SR  Planning  and  Design  IPT.  This  IPT  will  define  and  plan  the  integrated 
development  of  each  Block  increment  of  the  IC2ISR,  coordinating  designs  and  schedules 
among  component  developers.  The  IPT  identifies  the  “glueware”  necessary  to  integrate 
components  and  prepares  a  program  plan  for  each  block  with  appropriate  schedules  and 
funding  requirements.  Individual  components  are  developed  and  managed  by  the  SPOs, 
but  the  integration,  and  integration  specific  development  is  managed  by  the  IPT,  with 
SPO  members. 


-  C21SR  Configuration  Management  IPT.  This  IPT  will  create  an  inventory  of  existing 
C2ISR  systems  and  those  under  developmentincluding  their  present  configurations  and 
plans  for  future  modification,  upgrade,  disposal,  etc.  The  IPT  will  conduct  site  surveys  to 
aid  in  defining  the  C2ISR  baseline  from  which  to  begin  integration.  The  configuration  of 
the  baseline,  and  of  each  Block  as  the  IC2ISR  evolves,  will  be  controlled  by  the  IPT. 

-  C21SR  Certification  &  Deployment  IPT.  This  IPT  will  manage  the  Block  certification 
and  deployment  process  after  each  individual  C2ISR  system  has  completed  its 
development  and  is  ready  for  final  OT&E.  At  that  point,  the  individual  C2ISR  system  is 
taken  into  the  IPT  for  integration  with  the  other  Block  components.  An  integrated  OT&E 
is  conducted  of  the  new  Block  baseline  and  then  the  Block  is  deployed  as  an  integrated 
entity  with  the  support  and  resources  of  the  component  systems.  Individual  deployments 
of  single  C2ISR  systems  may  occur  in  isolated  cases,  but  generally  the  new  C2ISR  Block 
baseline  is  deployed  as  a  single  unit. 

-  C21SR  Sustainment  IPT.  This  IPT  will  develop  the  integrated  support  and  maintenance 
procedures  required  to  sustain  the  IC2ISR.  Eor  the  IC2ISR  to  be  of  value  to  the 
warfighter,  support  must  be  straightforward.  There  should  be  a  single  point  of  contact  for 
support  to  the  IC2ISR  and  any  of  its  components.  The  IPT  will  consolidate  the  support 
for  each  individual  component  with  support  for  the  IC2ISR,  and  will  manage  the 
continued  sustainment  of  the  IC2ISR. 

5.2  Changes  to  a  Typical  Acquisition  Process 

Current  acquisition  strategy  and  processes  for  C2  systems  are  not  structured  to  provide  adequate 
emphasis  for  I&I  issues.  By  definition,  I&I  issues  involve  more  than  one  system,  but  the  focus 
of  an  acquisition  program  is  on  a  single  system.  Because  of  this,  typically,  inadequate  attention 
is  paid  to  general  I&I  issues;  only  direct  interface  issues  for  the  particular  system  are  addressed. 

To  focus  the  necessary  attention  on  I&I  issues,  four  enhancements  are  proposed  to  the  standard 
acquisition  process.  Eigure  I  shows  a  typical  system  life  cycle  development  process,  from  IEEE 
Std  1220:  IEEE  Standard  for  Application  and  Management  of  the  Systems  Engineering  Process 
[IEEE  1998].  Eigure  2  shows  the  same  process  with  our  proposed  changes  to  facilitate  the 
development  of  IC2ISR. 

•  Explicit  IC2ISR  Definition  that  provides  a  context  for  system  definition. 

•  Explicit  IC2ISR  Requirements  input  as  the  system  is  being  defined. 

•  Explicit  IC2ISR  Design  as  part  of  the  design  phase. 

•  Explicit  IC2ISR  Test  and  Certification  for  deployment  as  an  integrated  unit. 
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Figure  1  -  Typical  System  Life  Cycle:  IEEE  Std  1220 
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Figure  2  -  Proposed  IC2ISR  System  Life  Cycle 


Note  that  the  internal  process  used  to  develop  a  component  is  not  greatly  impacted,  and  any 
effective  system  development  process  can  be  adapted  for  building  the  IC2ISR. 

5.3  Changes  to  a  Spiral  Development  Process 

AE  Instruction  63-123  Evolutionary  Acquisition  for  C2  Systems  [AE63-123]  directs  the  use  of  an 
Evolutionary  Acquisition  Strategy  with  a  Spiral  Development  Process.  Evolutionary  Acquisition 
is  an  acquisition  strategy  whereby  a  basic  capability  is  fielded  with  the  intent  to  develop  and  field 
additional  capabilities  as  requirements  are  defined.  It  is  being  adopted  by  the  Electronic  Systems 
Center,  the  Air  Eorce  center  for  C2  systems,  and  other  Air  Eorce  product  centers,  and  by  other 
services. 

Spiral  development  is  a  process  for  rapid  development  and  delivery  of  a  capability  to  warfighters 
in  the  field.  Characteristics  of  spiral  development  are  as  relevant  and  important  for  developing 
the  IC2ISR  as  for  other  systems  or  components.  They  can  be  adapted  as  follows: 


•  The  schedule  for  an  increment  is  fixed  from  funding  to  delivery. 

-  Eor  components  of  an  IC2ISR  Block,  delivery  is  contingent  on  delivery  of  the  entire 
Block. 

•  The  requirements  are  specified  as  performance  objectives. 

-  Eor  components  of  an  IC2ISR  Block,  the  performance  objectives  must  be  interpreted  in 
the  context  of  IC2ISR. 


•  There  can  be  tradeoffs  of  performance  in  order  to  maintain  the  schedule. 

-  For  components  of  an  IC2ISR  Block,  tradeoffs  must  be  interpreted  in  the  context  of 
IC2ISR. 

•  An  Integrated  Product  Team  (IPT)  representing  the  operational  user,  the  buyer,  the  testers, 
the  Program  Office,  and  any  other  stakeholders  that  may  be  affected  by  changes,  makes 
tradeoff  decisions  on  requirements. 

-  For  components  of  an  IC2ISR  Block,  the  IC2ISR  Integration  Office  is  a  critical 
stakeholder. 

•  The  operational  user  is  continually  involved  to  assure  the  utility  of  the  system  as 
requirements  evolve  and  to  make  the  decision  to  field. 

-  For  components  of  an  IC2ISR  Block,  the  IC2ISR  operational  users  must  also  be 
involved. 

5.4  Process  Timeline  Constraints 

The  various  refresh  cycles  discussed  in  Section  3.5  interact  and  interlock,  and  drive  the  IC2ISR 
block  schedules.  New  technology  refresh  implies  new  training.  All  refresh  cycles  require 
funding,  etc.  Integration  and  block  development  is  destined  for  failure  if  these  refresh  cycles  are 
ignored.  For  integration  programs  to  succeed,  the  acquisition  and  funding  processes  all  must 
accommodate  these  cycles.  They  define  the  integration  program  timelines. 

6.  Summary 

The  way  we  think  about  integration  in  the  acquisition  process  needs  to  change.  Integration  is  not 
an  attribute  of  a  system,  it  is  the  result  the  warfighter  needs  to  accomplish  the  mission.  When  it 
is  considered  as  a  result,  a  C2ISR  integration  program  does  not  adapt  readily  to  the  present 
acquisition  process.  The  differences  in  timelines,  and  the  diffusion  of  management  and  control 
in  the  development  of  the  multiple  components  that  comprise  each  block  of  the  IC2ISR,  impact 
all  of  the  functional  disciplines  of  the  standard  acquisition  process. 

The  acquisition  process  can  be  modified  to  accommodate  refresh  cycles.  An  Evolutionary 
Acquisition  Strategy  with  a  Spiral  Development  Process  can  accommodate  these  timelines,  but 
other  modifications  are  needed  to  address  problems  with  other  functional  disciplines.  The  most 
critical  are  management  and  funding.  There  is  an  irreducible  minimum  required  to  maintain  the 
integrity  of  the  IC2ISR,  to  provide  the  continuing  support  and  sustainment  for  the  system  to 
remain  viable.  In  addition,  because  integration  costs  can  only  be  roughly  estimated  at  this  time, 
funding  requirements  cannot  be  accurately  determined  in  advance. 

To  accommodate  the  PPBS  process,  rough  estimates  must  be  used  to  create  a  “funding  wedge”  in 
order  to  ensure  adequate  funding  on  an  annual  basis.  Strong  advocacy  is  needed  to  ensure  the 
program  is  not  jeopardized  if/when  costs  vary  considerably  from  estimates.  The  IC2ISR 
stakeholders  must  accept  this  approach  and  be  prepared  to  defend  it  throughout  the  PPBS 
process.  Assigning  C2ISR  programs,  and  IC2ISR,  to  a  single  MAD  would  ensure  a  focussed 
funding  advocate. 


A  single  C2ISR  PEO  is  needed  to  facilitate  C2ISR  integration.  Without  a  single  focal  point  for 
IC2ISR,  inadequate  funding  and  conflicting  requirements  will  typically  lead  to  decisions 
favoring  individual  components  or  systems,  rather  than  the  IC2ISR.  The  integration  program 
should  be  managed  through  an  Integration  Office  reporting  to  the  PEO.  This  Integration  Office 
would  lead  IPTs  to  manage  the  integration  effort. 

When  IC2ISR  becomes  a  reality,  components  can  be  developed  as  integrated  pieces  of  the 
whole,  rather  than  pieces  to  be  integrated  into  the  whole.  New  technologies  and  capabilities  can 
be  developed  and  fielded  as  integrated  components  of  IC2ISR,  not  as  stand-alone  systems. 
Integration  costs  will  be  reduced,  and  even  eliminated  in  the  long  term.  Costs  of  fielding  new 
technologies  will  be  reduced  through  leveraging  of  hardware  and  software  in  the  integration 
environment. 

The  warfighter  does  not  fully  recognize  the  value  of  IC2ISR.  The  value  will  be  apparent  only 
when  integrated  C2ISR  becomes  a  reality.  It  will  be  apparent  when  the  multiplicity  of  systems  is 
reduced,  which,  in  turn,  reduces  the  complexity  of  testing,  documentation,  training  and 
sustainment.  This,  in  turn,  reduces  costs,  including  manpower  needs.  Once  IC2ISR  is 
established,  it  will  facilitate  the  development  and  fielding  of  new  capabilities  and  new 
technologies  for  the  warfighter,  and  simplify  their  utilization. 
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